System and method for specified pool trading

ABSTRACT

A computer system and related methods configured to store and deliver, upon request, information related to asset-backed security pools, and execute transactions between one or more parties relating to the same. The system generally comprises a computer and a network interface that includes a data storage system in communication with the computer, the data storage system storing information relating to the securities, and account information related to at least one or more parties. The computer operative to provide information related to security pools to at least one of the parties, enable the at least one party to select one or more security pools for inclusion in a specified pool, provide aggregate pool data and information related to the selected specified pool to at least one other party, receive pricing information from at least one other party, and execute a trade for the asset-backed security pools in the specified pool.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/964,526, filed on Aug. 12, 2013, which is a continuation of U.S.patent application Ser. No. 12/401,084, filed on Mar. 10, 2009, whichclaims priority under 35 U.S.C. § 119(e) to co-pending ProvisionalPatent Application No. 61/035,295, filed Mar. 10, 2008, and ProvisionalPatent Application No. 61/047,644, filed Apr. 24, 2008, the entiredisclosures of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION Field of the Invention

The embodiments of the present invention relate to a system and methodfor specified pool trading and, in particular, to a system and methodfor the creation, communication, price quotation, and execution oftrades for specified pools of asset-backed securities.

Description of the Related Arts

Asset-backed securities are bonds that are backed by, or in other words“invested” in, a pool of assets, such as mortgages. Asset-backedsecurities use a pool of assets to diversify the security's holdings andreduce risk that the failure of any one asset in the pool will have adisproportional effect on the value of the whole.

The trading of asset-backed securities, such as mortgage-backedsecurities (MBS), has typically been performed on a to-be-announced(TBA) basis in which the buyer (also known as the “liquidity taker”) andseller (also known as the “liquidity provider”) agree on the generalterms of the trade for a pool of assets. However, the specific assetsthat will be included in the security are not selected and are onlyrevealed by the seller days after the trade, but in advance of thesettlement of the trade. Thus, while the buyer can achieve a generalinvestment objective through TBA trading, the buyer is unable to trulycustomize the security.

In the alternative, specified pool trading permits the buyer to selectspecific asset-backed securities to be included in the pool such thatthe details of the pool of assets is known to the buyer at the time ofthe trade. Thus, unlike TBA trading, the seller provides information tobuyers about various asset-backed securities and the buyer makes itsselections from the group of asset-backed securities provided by theseller. Due to the transparency, specified pool trading is generallyhigher cost than TBA trading.

In the recent market environment, buyers of asset-backed securities maybegin to focus on the need to pick and choose the specific asset pools,namely specified pools, that may outperform or meet more particularizedgoals than generic TBAs. The ability to more accurately forecast thebehavior of individual pools by better understanding the specificcharacteristics of the loans (and their respective borrowers in the caseof MBS) can provide buyers with an additional ability to develop tradingstrategies virtually regardless of the market environment. This is one,among many, objectives of the present invention.

One of the technical problems with the current state of specified pooltrading, particularly, in the mortgage-backed security markets, forexample, is a lack of liquidity to adequately meet the needs of agrowing focus on this type of financial instrument. This is becausecurrent systems and methods for trading specified pools ofmortgage-backed securities are cumbersome and fail to provide anefficient and accessible platform for permitting liquidity providers(e.g., dealers; also known as market-makers) to offer various types ofmortgage-backed securities, and for permitting liquidity takers (e.g.,other dealers, investors and buy-side customers) to access a database ofMBS, either specify criteria for stipulated pools or select one or moremortgage-backed securities to create a specified pool list, or selectcriteria for a to be created specified pool. Moreover, other systemsfail to provide mechanisms permitting market participants to submit theselected pool(s) to one or more sellers, receive quotes from thesellers, and conduct trades for the specified pools. Additionally,current systems and methods fail to provide customers of asset-backedsecurities, such as MBS, the ability to specify criteria for a pool thatis not currently listed in a seller's inventory, and submit thatcriteria to the seller for creation of a stipulated pool. The currentmethods for trading specified pools of asset-backed securities also failto permit the straight-through-processing of specified pool trades. Thelack of liquidity may ultimately lead to increased transaction costs andpremiums over TBAs, and other inefficiencies. It, therefore, is anotherobjective of the present invention, among others, to overcome some orall of the technical problems in the art.

SUMMARY OF THE EMBODIMENTS OF THE INVENTION

Embodiments of the present invention generally comprise acomputer-implemented method for creating specified pools lists ofasset-backed security pools, or alternatively creating characteristicsets for a customized specified pool to be created, and thereaftercommunicating, exchanging price quotations, and executing trades forspecified pools of asset-backed securities using a system capable ofcommunication with a buyer computer and a plurality of seller computers.Although certain examples provided herein describe the embodiments ofthe invention in the context of mortgages, persons skilled in the artwill recognize that other assets may be utilized within the scope of theinvention. One advantage, among others, of the present invention is thatit reduces risk on the operational side of the trading, purchase or saleof asset-backed securities, and provides increased availability andliquidity in such products.

Generally speaking, as known to industry and market participants, a“specified pool” is a specific security in which the buyer knows inadvance what assets comprise the specified pool. In the case ofmortgage-related securities, these pools are typically guaranteed (alsoknown as “stamping”) by one of the three mortgage-related agencies orGSEs: (1) Fannie Mae, (2) Freddie Mac, and (3) Ginnie Mae. In thecontext of certain embodiments of the present invention (e.g., thosewhere a set of characteristics for a yet to be created specified poolare defined by a buyer) the term “specified pools” is used more broadlyto include asset-backed securities in which a buyer and seller come toan agreement on a specific grouping or pool of assets even though thatpool may not yet have been, in the case of MBS, guaranteed and given aCUSIP by one of the GSEs. In accordance with embodiments of the presentinvention, it is intended that such specified pools created using themethods and systems disclosed herein will be submitted to theappropriate GSE or other agency or entity, as applicable, to beguaranteed as is known in the art.

In one embodiment, a method in accordance with such a system generallycomprises: (i) providing information relating to a plurality ofasset-backed security pools (e.g., pools of mortgages) to buyer usingthe buyer computer; (ii) receiving from the buyer computer a selectionof one or more asset-backed security pools; (iii) creating a specifiedpool list of asset-backed security pools based on the selection of oneor more asset-backed security pools; (iv) causing the specified poollist to be displayed on at least one of the plurality of sellercomputers; (v) receiving pricing from the at least one of the pluralityof seller computers for the specified pool list; and (vi) executing atransaction for the specified pool lists at the pricing received fromthe at least one of the plurality of seller computers for the specifiedpool list.

The method may further comprise retrieving information for each of theasset-backed security pools from a source, and causing the display ofthe information on the buyer computer. Moreover, such a method mayinclude receiving a criteria for the asset-backed security pools fromthe buyer computer and wherein the retrieving step comprises retrievinginformation for each of the mortgage-backed security pools from thesource based on the criteria.

In some embodiments, the method of creating the specified pool ofasset-backed securities further comprises: generating a matrix ofasset-backed security pools based on the selection of one or moreasset-backed security pools, and calculating aggregate informationrelated to the matrix of one or more asset-backed security pools. Theaggregate information may include aggregated data related to at leastone indicator for one or more of the selected asset-backed securitypools, wherein, at least in some instances, such as in connection withmortgage-backed securities, the indicator is selected from the groupconsisting of a CUSIP or other identifier number, a pool number, aweighted average maturity, a weighted average coupon, a constantprepayment rate, an originator identifier, an average loan size, amaximum loan size, one or more geographic loan locations, and an averageFICO score.

In accordance with various embodiments, such methods may furthercomprise causing the specified pool list to be displayed on at least oneof the plurality of seller computers, such the display of a matrix ofasset-backed security pools. In this way, one or more sellers canprovide pricing for the specified pool list (e.g., in the form of aspread from the at least one seller). The buyer may then select pricingfrom one of the plurality of sellers for all of the asset-backedsecurity polls in the specified pool list, or select pricing from atleast two of the plurality of sellers for a portion of the asset-backedsecurity polls in the specified pool list.

In an alternative embodiment, a method of creating the specified pool ofasset-backed securities comprises: receiving an inquiry message from abuyer wherein the inquiry message includes one or more characteristicsfor a pool of assets; generating an inventory request message andcausing the display of said inventory request message on a sellercomputer; and receiving an offer message from the seller computerincluding information related to an asset-backed security thatcorresponds to at least a portion of the characteristics for a pool ofassets included in the inquiry message. As will be described in greaterdetail, the asset-backed security may be a security existing in theinventory of the seller or a new pool of assets created by the sellerfor the purpose of meeting the buyer's requested characteristics.

A system in accordance with the various embodiments of the presentinvention generally comprises a computer system designed and configuredto store and deliver upon request information related to a plurality ofasset-backed security pools. The computer system is capable ofcommunication with one or more buyers and one or more sellers at anygiven time. The computer system is preferably programmed to provideinformation related to a plurality of asset-backed security pools,enable a buyer to select one or more pools for inclusion in a specifiedpool list, provide aggregate pool data related to the selected specifiedpool list, provide information related to the selected specified poollist to one or more sellers, receive pricing information from the one ormore sellers, and execute a trade for one or more selectedmortgage-backed securities in the specified pool list.

In addition, an embodiment of the invention comprises a computer programembodied on a computer readable medium for creating a specified pool ofasset-backed securities, which includes (i) a pool section modulecomprising programming to cause a computer to: retrieve informationrelating to a plurality of asset-backed securities from a database incommunication with the computer; transmit the information through anetwork to a buyer computer, and receive a selection signal from thebuyer computer, the selection signal including an indication of at leastone or more asset-backed security pools or individual asset-backedsecurities; (ii) an order creation module comprising programming tocause the computer to: create a specified pool list based on theselection signal received from the buyer computer; (iii) a tradenegotiation module comprising programming to cause the computer to:transmit the specified pool list to at least one seller computer andreceive a price signal representing a dollar amount for the asset-backedsecurities in the specified pool list identified from the sellercomputer; and (iv) an execution module comprising programming to causethe computer to: transmit the price signal to the buyer computer;receive an authorization signal from the buyer computer in response tothe price signal, and execute a transaction based on the specified poollist and the price signal.

Additional features and advantages of the present invention aredescribed further below. This summary section is meant merely toillustrate certain features of the invention, and is not meant to limitthe scope of the invention in any way. The failure to discuss a specificfeature or embodiment of the invention, or the inclusion of one or morefeatures in this summary section, should not be construed to limit theinvention as claimed.

BRIEF DESCRIPTION OF THE FIGURES

Embodiments of the invention will be described and shown in detail byway of example with reference to the accompanying drawings in which:

FIG. 1 is a schematic diagram of an embodiment of a system in accordancewith the present invention;

FIG. 2 is an alternate view of a system in accordance with the presentinvention;

FIG. 3 is an inventory filter graphical user interface for creating asecurity query in accordance with the present invention;

FIG. 4 is a graphical user interface for reviewing the results of aninventory query in accordance with the present invention;

FIG. 5 is a graphical user interface of a trade matrix in accordancewith the present invention;

FIG. 6 is a graphical user interface of a “list in” ticket in accordancewith the present invention;

FIG. 7 is a graphical user interface of a first type of “bid list”ticket in accordance with the present invention.

FIG. 8 is a graphical user interface of a second type of “bid list”ticket in accordance with the present invention;

FIG. 9 is a flow diagram showing an embodiment of a quoting protocol inaccordance with the present invention;

FIG. 10 is a graphical user interface for setting spot prices inaccordance with the present invention;

FIG. 11 is a trade completion message box in accordance with the presentinvention; and

FIG. 12 is a graphical user interface for specifying the attributes ofan asset-backed security in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In accordance with various embodiments of the invention, and as shown inthe FIGS., various systems and methods are disclosed which generallyprovide a platform for the creation, communication, price quotation, andexecution of trades for specified pools of asset-backed securities.

With reference to FIG. 1, there is shown a preferred embodiment of asystem 10, which generally comprises one or more computer systems anddatabases and related database management systems. One skilled in theart will recognize that the computer systems may as a matter of designchoice include any number and configurations of computers and databases,which may be used separately or in tandem to support the traffic andprocessing needs necessary in operation at one time. If multiplecomputers are used, the computer may be configured using a round-robinconfiguration to handle end user traffic.

Although not depicted in the figures, the one or more computers ofcomputer system 10 generally include such art recognized components asare ordinarily found in such computer systems, including but not limitedto processors, RAM, ROM, hard disks or other computer readable mediums,clocks, hardware drivers, associated storage, and the like. Referencesherein to the term “database” or “database system” generally refer toone or more storage devices or computers with storage media storing acollection of records or data, as well as software for managing suchrecords or data (commonly known as a database management system (orDBMS)). The database may take the form of a relational, hierarchical,network, or other known structure as may be deemed to be most efficient.In a preferred embodiment, the present invention employs a relationaldatabase to store the various associations of data described herein.

Furthermore, each of the computer systems described herein preferablyincludes a network connection (not shown). The network connection may bea gateway interface to the Internet or any other communications networkthrough which the systems can communicate with other systems and userdevices. The network connection may connect to the communicationsnetwork through use of a conventional modem (at any known or laterdeveloped baud rate), an open line connection (e.g., digital subscriberlines or cable connections), satellite receivers/transmitters, wirelesscommunication receivers/transmitters, or any other network connectiondevice as known in the art now or in the future.

With reference to FIG. 2, there is shown another view of a systemarchitecture in accordance with a preferred embodiment of the presentinvention in which system 10 is interconnected via network 50 to one ormore buyer and seller computer systems 25, 35. Moreover, as illustratedin FIG. 2, the system 10 preferably utilizes a distributed softwareapplication arrangement to provide the processing of transactionsinvolving asset-backed securities. Although the embodiments describedherein are described in terms of a distributed, networked softwaresolution operative in a client-server environment, a wholly server-basedor client-based approach could be adopted, so long as the system wasconfigured to provide the functionality disclosed herein. As notedabove, network 50 may be a gateway interface to the Internet or anyother communications network through which the systems can communicatewith other systems and user devices. The connection may also be a directconnection for security purposes.

Buyer and seller computers 25, 35 can be any type of personal or networkcomputer such as an IBM-compatible computer running an Intel chipset andhaving an operating system, such as Microsoft Windows NT, 2000, XP,Vista and the like, and, preferably, running a browser program such asMicrosoft Internet Explorer, Netscape Navigator, or Mozilla Firefox.Apple-based computer systems can also be used within the context of thesystem being disclosed. It is also within the scope of the presentinvention that computers 25, 35 may be handheld or table computingdevices, such as a personal digital assistant (PDA), pocket PC, andtablet PC, iPhone device, or the like. Computers 25, 35 preferably haveaccess to a communications network via a modem or broadband connectionto permit data communication between the participants and the system 10.

Various input and output devices are preferably provided with the buyerand seller computers 25, 35 including, by way of non-limiting example, adisplay (e.g., cathode ray tube (CRT), liquid crystal display (LCD),etc.), and an input device (e.g., a keyboard, mouse, touch pad, or lightpen). The buyer and seller computers 25, 35 would also preferablyinclude a storage device such as, for example, a magnetic disk drive andmagnetic disk, a CD-ROM drive and CD-ROM, DVD, or other equivalentdevice. The specific hardware combination/configuration may vary as amatter of design choice within the functional parameters disclosedherein. Buyer and seller users of the system 10 typically interact withthe GUI's displayed by the software modules by “clicking” on numbers orgraphics (e.g., buttons) that are displayed on the GUI's. Persons ofskill will understand that the present invention is not limited toclicking with a computer mouse, but includes use of any other device forindicating an action with graphics-based software, such as a touch pad,light pen, touch sensitive display screen and the like.

With reference back to FIG. 1, system 10 is also preferablyinterconnected with a straight-through-processing system 5, as isdisclosed by U.S. Pat. No. 7,433,842 issued on Oct. 7, 2008, andentitled “Method and System for Effecting Straight-Through-Processing ofTrades of Various Financial Instruments,” the entire disclosure of whichis incorporated herein by reference.

System 10 generally includes an order creation module 12, a tradenegotiation module 14, a list response manager 15, and an executionmodule 16, as well as a database 18 for storing data related toasset-backed securities, market data, buyer account information, andrelated data. The order creation module 12, trade negotiation module 14,list response manager 15, and execution module 16 generally comprisecomputer programming operative on one or more computers to perform thefunctions described herein.

In general, order creation module 12 has two modes of functionality. Ina first mode, order creation module 12 permits a buyer to search adatabase of specified pools and to select one or more pools from theinventory for pricing by a selected group of sellers. It will beunderstood from the following disclosure that, although multiple poolsare selected, and number of pools less than the total number selected(or none at all) may be quoted and ultimately traded. In a second mode,a buyer is provided with the option to select thee characteristics of adesired specified pool. These characteristics may be transmitted throughsystem 10 to one or more sellers. The sellers can identify one or morepools in their respective inventories that substantially meet the buyersspecified set of characteristics or agree to create a specified poolmeeting such characteristics.

With reference of a first mode of order creation module 12, system 10can provide functionality to buyers to review the details of variousasset-backed securities which are stored in database 18. Such detailstypically include, for instance in connection with a mortgage-backedsecurity, a CUSIP number (or other identifier), a pool number, aweighted average maturity, a weighted average coupon, a constantprepayment rate, an originator identifier, an average loan size, amaximum loan size, one or more geographic loan locations, and an averageFICO score. By way of example, as shown in FIG. 3, an inventory filterGUI 300 provides a number of filter options to enable the buyers tosearch for mortgage-backed securities meeting defined criteria. In theexample shown, GUI 300 includes a criteria zone 310 and a dealer listzone 350. The criteria zone 310 is used to define the criteria accordingto which the desired securities will be pulled from database 18. Thedealer list zone 350 includes a list of sellers and correspondinggraphical toggle buttons 352 to enable the buyer to select the sellers(e.g., dealers) for which the buyer desires to view appropriatesecurities. In other words, by defining the criteria in criteria zone310 and selecting dealers in dealer list zone 350, the buyer can returnspecific securities meeting the defined criteria and being offered bythe selected dealers.

The criteria, as shown in FIG. 300, preferably includes a minimum sizefield 312, a weighted average loan to value 314, a coupon size field316, a weighted average coupon field 318, a weighted average maturityfield 320, a weighted average loan age 322, FICO score 324, statelimiters 326, 328, 330, and an interest only drop down menu 332. In apreferred embodiment, GUI 300 also includes a maximum loan balance field334, which includes a plurality of max loan balance levels selectablethrough use of radio buttons. As a further feature, in a preferredembodiment, GUI 300 also includes a sort order field 336, which enablesthe buyer to customize the sort order of the results by variouscriteria, including but not limited to face value, issuer, weightedaverage coupon, weighted average maturity, coupon, and FICO score.

In operation, by setting various criteria and through selection of oneor more sellers, through the operation of order creation module 12,buyers can create a customized inventory query which will returnavailable asset-backed securities from database 18. In the alternative,as described further below, the query can be submitted directly to theseller in order to determine whether the seller has or can stipulate toan asset-backed security meeting the buyer's requirements. This featuremay be used when a security meeting the buyer's requirements is not inthe inventory of one or more sellers.

With reference now to FIG. 4, there is shown a preferred embodiment ofgraphical interface 400 (generated by order creation module 12) forviewing the result of an inventory query submitted through GUI 300.Inventory offering GUI 400 comprises an inventory list section 410 and asecurity data section 450. The inventory list section 410 preferablyincludes a number of fields related to the display of asset-backedsecurities; namely, a seller identifier 412, issuer identifier 414, poolnumber 416, coupon rate 418, original face value 420, current face value422, factor 424, spread 426, benchmark 428, benchmark price 430 andother information know in the art to be pertinent to the trading of theparticular asset-backed security at issue.

Security data section 450 preferably also displays a variety of datarelevant to the trading of the security. In the case of mortgage-backedsecurities, security data section 450 can include the following data,among other pertinent information: a CUSIP number (or other identifier),a pool number, a weighted average maturity, a weighted average coupon, aconstant prepayment rate, an originator identifier, an average loansize, a maximum loan size, one or more geographic loan locations, and anaverage FICO score. Table I below sets forth a preferred embodiment ofthe list creation columns and various options:

TABLE I Column Hide if Default Global Name Description OUTRIGHT ControlValue Setting Select Box Check Box Check Box Selected Yes # Dealers Thenumber of dealers Output only Not selectable No currently selected forthe line item Buy/Sell Clicking B/S button flips Toggle Not selected Yesfield. Button unless user cut For AON Swap list, the and pastes thebenchmark & pool value from or directions must be EXCEL inversedOriginal Minimum value = 1k Input None Yes - Pool Qty Existing limits onapplies (000) outright tickets should be same respected. quantity toentire column CUSIP/ User can enter pool Input None No Identifierdescription or CUSIP. System will “look up” security from user entryMultiple matches will display in the benchmark field. Summary line willdisplay total number of pools Pool Desc. If a partial match is OutputTWEB No found during a paste or Standard manual entry, this fielddescription will display Choose Security Current Summary line displaysOutput Pool current No Face the total current face of face from allpools security database Benchmark If AON is set, the user Drop Down Usethe Yes - can enter a single benchmark benchmark in the associated withGLOBAL field to set for the first pool in the entire list. the list Ifindividual, the user can change any issue Benchmark YES Input Same asOrig Qty pool Qty Type Defaults from user Toggle User Yes preferenceButton preference Only appears on the summary line for AON lists.Displays on each line for individual lists Pool Settle Global settingapplies to Dropdown Same as Yes pools only benchmark TBA Settle YesOutput TBA settle No Brkdn Opens the account Toggle No breakdown pageButton Note Max characters is Input This column should be added to allproducts and associated dealer software list tickets.

In one embodiment, on inventory offering GUI 400, a buyer can select oneof the specified pools or a plurality of pools to be included in aspecified pool list. In a preferred embodiment, order creation module 12can be programmed to display the selected securities on a trade matrixGUI 500, as shown in FIG. 5. The trade matrix GUI 500 preferablyincludes a security list section 510, which preferably contains similarinformation and layout to the inventory list section 410 of inventoryoffering GUI 400. The security list section 510 can include one or moreadditional features for defining the type of transaction (e.g., buy,sell, or swap), as depicted by graphical button 512, or for defining thesettlement date, as depicted by field 514, or for performing an action,as depicted by action button 516.

GUI 500 can also include an aggregate pool data section 550 in additionto a static security data section 570. Aggregate pool data section 550preferably displays aggregate data for the asset-backed securities inthe security list section 510, in order to provide the buyer anindication of the nature of the pool being created by including one ormore of the securities listed in the security list section 510. In thisway, order creation module 12, in a preferred embodiment, can beprogrammed to generate aggregated pool data for the selected pools, sothat the buyer can efficiently and effectively customize the desiredorder. In a preferred embodiment, aggregate pool data section 550includes an aggregate original face value field 552, an aggregatecurrent face value field 554, and an aggregate market value field 556.

In an alternative embodiment, wherein one or more desired securities arenot in inventory order creation module 14 can be programmed to permit, abuyer to send an inquiry message to one or more sellers inquiring as tothe availability of a security meeting the buyer's needs. In thisembodiment, a buyer typically creates an order query using system 10'sorder creation module 12 to determine whether the desired security islisted in database 18. As previously described in connection with FIG.3, such query details typically include, for instance in connection witha mortgage-backed security, a CUSIP number (or other identifier), a poolnumber, a weighted average maturity, a weighted average coupon, aconstant prepayment rate, an originator identifier, an average loansize, a maximum loan size, one or more geographic loan locations, and anaverage FICO score. While the buyer will generally first use inventoryfilter GUI 300, as shown in FIG. 3, to enable the buyer to search formortgage-backed securities meeting defined criteria, in some instances,the desired security may not be available. In those instances, the buyercan use criteria zone 310 to define the criteria according to which aninquiry message will be generated and transmitted to one or moresellers. The dealer list zone 350 includes a list of dealers, acting assellers, and corresponding graphical toggle buttons 352 to enable thebuyer to select the dealers to which the inquiry message will betransmitted.

Once the buyer completes the process of inputting desired criteria andselecting dealers, the criteria and dealer data is transmitted to andreceived by system 10. System 10 then generates an inquiry message whichincludes the characteristics for the pool of assets defined by thebuyer. The data in the inquiry message is then transmitted to theselected dealer computer 35. FIG. 12 depicts a preferred embodiment ofan inventory request message that includes data in the inquiry messageand which is caused to be displayed on the dealer computer 35. As shownin FIG. 12, on the top portion of GUI 1200, several desiredcharacteristics of a desired security are displayed. In the exampleshown in FIG. 12, such characteristics for a mortgage-backed securityinclude, but are not limited to, size 1202, max loan balance 1204,issuer 1206, program 1208, coupon range 1210, weighted average coupon1212, weighted average maturity 1214, weighted average loan age 1216,FICO score 1218, weighted loan to value 1220, and geographic percentages1222.

Using the inventory request GUI 1200, the dealer can review the criteriadesired by the buyer and either offer a pool from the dealer's inventoryor stipulate to a new pool by defining some or all of the pool'scharacteristics. An inventory pool can be selected using the “pool #”drop-down menu 1230, which includes a plurality of available poolsecurities in the dealer's internal inventory. Alternatively, the dealercan use the mine functionality (see graphical button 1275) to search foradditional available pool securities. In another alternative, the dealercan define certain characteristics of a stipulated, to be created pool,using the fields located on the lower half of GUI 1200. Specifically, ina preferred embodiment for a mortgage-backed security, such fieldsinclude, but are not limited to, a CUSIP/Identifier field 1232, couponrate 1234, weighted average maturity 1236, weighted average coupon 1238,weighted average loan age 1240, size 1242, spread 1244, maximum loanbalance 1246, benchmark 1248, and factor 1250.

The data defined by the dealer is then transmitted to system 10 and onto the buyer computer 25. The securities defined by the dealer can thenpreferably be reviewed side-by-side with the securities initially foundin the inventory listing of database 18.

Once the buyer is satisfied with the list of asset-backed security pools(e.g., MBS pools), the specified pool list can be transmitted throughsystem 10 to the list of selected sellers. In a preferred embodiment,this action causes the calling of trade negotiation module 14, whichoperates in conjunction with list response manager 15 and executionmodule 16 to spot (or price) the specified pool list, otherwisenegotiate the trade details, and ultimately execute a trade for therequested specified pool list. In operation, the trade negotiationmodule 14 will call the list response manager 15 to enable the seller,using the seller computer 35, to provide quotes in response to thereceipt of a specified pool list. Preferably, the trade negotiationmodule 14 then transmits the quoted list information back to the buyerfor review and acceptance. If there are multiple competing sellers, thebuyer will need to choose between the buyers. Once there is acceptance,trade negotiations module 14 will call execution module 16 which willexecute a trade and provide any “last look” options, as described ingreater detail below, that may be optionally programmed into executionmodule 16.

On the seller computer 35, in a preferred embodiment, a list-in ticket600, as shown in FIG. 6, can be caused by system 10 to be displayed onthe seller computer 35. List-in ticket 600 can include a “due at” time605, a buyer identifier 610, an aggregate size indicator 615, and anumber of items indicator 620 (e.g., to identify the number of specifiedpools in the list). List-in ticket 600 can also include an “open list”selection item 625 and a “defer list” selection item 630. As shown inFIG. 6, selection items 625, 630 are preferably graphical buttons.

If the “open list” selection item 625 is “clicked” by a seller, a bidlist ticket 700, as shown in FIG. 7 can be displayed. From the sellerperspective, a list response manager module 15 (depicted on FIG. 1)preferably provides traders with the ability to “construct” their bidlist responses. As shown in FIG. 7, a bid list ticket 700 preferablyincludes a pool list section 705, which includes relevant data (e.g.,pool quantity, pool identifier, benchmark, benchmark quantity, type,spread, etc.) concerning the pools selected at the buyer computer 25 tobe included in the specified pool. Additionally, several graphicalselection items 710, 712, and 714 can be included to permit the sellerto customize the transaction. For example, using “+/−” buttons 710, theseller can enter spread in the spread field 707. The “+/−” button 710preferably increments spread in ⅛th of a 32nd. The send buttons 712,cause the spread to be transmitted through system 10 to the buyercomputer 25. Clicking on the pass buttons 714 will send a pass to thebuyer. It is preferred, however, that the seller can “UnPass” a tradeand resubmit a spread to the buyer. With reference to the top right handcorner of GUI 700, a “due in” time indicator 720 and a “good for” timeindicator 722 are preferably displayed to the seller to facilitatetimely creation of the trade. As shown in FIG. 7, a portion 730 of thebid list ticket can be a context sensitive area that preferably showssome fundamental data about the security.

With reference now to FIG. 8, the seller can use the bid list ticket 800to input the individual spot trade for each specified pool (unless thetrade has been designated as an AON trade). In a preferred embodiment,bid list ticket 800 includes a spot field 805 that preferably defaultsto the TBA composite price generated by system 10's pricing engine. Theseller can increase or decrease the spot pricing by using “+/−” buttons810. The “send” button 815 transmits the spot price to the buyer fornegotiation.

A preferred embodiment of a quoting protocol will now be described withreference to FIG. 9. In one embodiment, the quoting protocol is all ornone (i.e., AON). In other words, the seller submits a spread for theentire specified pool list, such that the spread is applied to eachindividual pool in the list, and the final pool price is computed afterthe TBA is spotted. Alternatively, a buyer can request spot prices formultiple trades. In a preferred embodiment, the trades must be from thesame specified list, of the same direction (e.g., buy or sell), andshare the same benchmark. Referring back to FIG. 9, the ‘Due In’ time ispreferably set at the discretion of the buyer. Once the specified ‘DueIn’ time is equal to zero, in step 905, the buyer defined “TradingSession” will begin ticking to zero, in step 910. As this point, sellingtraders can (i) update quotes any time prior to expiration of “TradingSession” (step 915); or (ii) send an initial quote any time prior to theend of the “Trading Session” (step 920).

During the execution phase, as operative by the execution module 16, itis preferred that when a buyer executes, the seller will have a “lastlook” option in order to accept, pass, or counter the trade, in step925. Seller can preferably manage the “last look” actions via the bidlist ticket. Thus, if an individual trade is being executed, therelevant trade for which the buyer is attempting to execute will behighlighted and active and all other trades will be disabled.

If the buyer requests spot prices, in step 930, the system 10 can causethe display of a GUI 1000, as shown in FIG. 10, with the selected poolsto be spotted 1010, relevant information for the list 1020, and “+/−”buttons 1030 for setting the spot price. As each individual pool isspotted, in step 935, another GUI 1100, as shown in FIG. 11, can becaused to be displayed to either or both of the buy-side or sell-sideusers indicating that the trade is completed. GUI 1100 preferablyincludes several details of the trade, including without limitation adescription 1105, face value 1110, current face value 1115, spread 1120,spot 1125, price 1130, and the settlement date 1135. At this point inthe process, in step 940, the trade(s) can be imported into the system10's straight-through-processing module.

In a preferred embodiment, as a further feature, the list responsemanager 15 is programmatically configured to provide various aggregationfeatures that generally permit certain like pool trades to be aggregatedfor spotting purposes. Typically, if a specified pool list has not beendesignated all-or-none, then each individual pool in the list must bespotted to a benchmark, i.e., the seller will provide a spread for eachpool. However, this process is highly inefficient. In the preferredembodiment being described, these inefficiencies are technically solvedthrough the addition of a logical aggregation component to the listresponse manager 15 wherein, for example, similar pools in a list (e.g.,Fannie Mae 5½ mortgage backed securities) are aggregated and spotted asa group. In this way, a single spread can be applied by a seller to anentire group of like securities. Alternatively, the aggregationcomponent of the list response manager 15 preferably may be configuredto provide aggregation across multiple trade requests that include likesecurities and which are submitted to the same seller. For instance, abuyer may create two specified pool lists wherein each list includesFannie Mae 5½ MBSs and wherein the lists are both received by the samedealer. Here, a single spread quote can be efficiently applied to all ofthe Fannie Mae 5½ MBSs even though the securities are in separate lists.In the AON context, in a preferred embodiment, a seller must take all ornone and, therefore, the quoting protocol is preferably performed as asingle pay-up for the entire list, as opposed to providing spread quotesfor individual or aggregated securities.

While there have been shown and described fundamental novel features ofthe invention as applied to the exemplary embodiments thereof, it willbe understood that omissions and substitutions and changes in the formand details of the disclosed invention may be made by those skilled inthe art without departing from the spirit of the invention.

We claim:
 1. A non-transitory computer program product, comprising acomputer usable medium having a computer readable program code embodiedtherein, said computer readable program code comprising: a database; apool selection module in communication with the database; an ordercreation module in communication with the pool selection module a tradenegotiation module in communication with the order creation module; andan execution module in communication with the trade negotiation module;said computer readable program code performing the steps of: (i)retrieving by the pool selection module information relating to aplurality of mortgage backed securities from the database, (ii)transmitting by the pool selection module the information through anetwork to a buyer computer, (iii) receiving by the pool selectionmodule a selection signal from the buyer computer, the selection signalincluding an indication of at least one or more mortgage backed securitypools; (iv) creating on a processor by the order creation module aspecified list of mortgage backed security pools based on the selectionsignal received from the buyer computer wherein each of themortgage-backed security pools that are part of the specified list isassociated with a unique CUSIP number and contains a pool factor that isreflective of the principal left to be distributed in each of themortgage-backed security pools; (v) transmitting by the tradenegotiation module the specified list to at least one dealer computerand receiving a price signal from the dealer computer representing adollar amount for the mortgage backed securities in the specified list;(vi) transmitting by the execution module the price signal to the buyercomputer, (vii) receiving by the execution module an authorizationsignal from the buyer computer in response to the price signal, and(viii) executing a transaction by the execution module based on thespecified list and the price signal wherein each of the mortgage backedsecurity pools in the specified list has been guaranteed by a governmentsponsored enterprise (GSE).
 2. A non-transitory computer programproduct, comprising: a computer usable medium having a computer readableprogram code embodied therein, said computer readable program codeadapted to be executed to perform the method comprising the steps of:operating a system, wherein the system comprises distinct softwaremodules, and wherein the distinct software modules comprise an ordercreation module, a trade negotiation module, a list response manager,and an execution module; retrieving information relating to a pluralityof mortgage-backed securities from a database in communication with thesystem through a network to a buyer computer, and displaying theinformation on a remote computer, and wherein the retrieving isperformed by the order creation module in response to a pool selectioninitiation signal received from the remote computer; receiving aninquiry signal from the remote computer, the signal including criteriarelated to one or more mortgage-backed security pools; obtainingsecuritization of the mortgage-backed security pools from a governmentsponsored enterprise; displaying of an inquiry message on a selectedseller computer, the inquiry message including the criteria; receivingfrom the selected seller computer, information relating to the one ormore mortgage-backed security pools based upon at least a portion of thecriteria; displaying of the received information on the remote computer;receiving a selection signal from the remote computer, wherein theselection signal includes an indication of at least one of the one ormore mortgage-backed security pools, each of which is associated with aCUSIP number and a pool factor that is reflective of the principal leftto be distributed in each of the mortgage-backed security pools, beingselected from the plurality of the one or more mortgage-backed securitypools, and wherein when the selection signal is received, the ordercreation module creates on a processor a specified list based on theselection signal received from the remote computer, and wherein theorder creation module then calls the trade negotiation module;displaying of the specified list that is displayed on at least oneseller computer, along with an interface prompting input of a price forat least one of the mortgage-backed security pools represented in thespecified list, and receiving from the seller computer a price signalrepresenting the inputted price for the mortgage-backed security poolsrepresented in the specified list, wherein the generating and receivingis performed by the trade negotiation module in conjunction with thelist response manager; and displaying of the price signal that isdisplayed on the remote computer, along with an interface for reviewingand accepting or rejecting the price signal at the remote computer, andexecuting a transaction based on the specified list and the price signalin response to receipt of an authorization signal received at the systemfrom the remote computer.
 3. A computer system designed and configuredto store and deliver, upon request, information related to a pluralityof mortgage backed security pools, and to execute transactions betweenone or more parties relating to at least one of the plurality ofmortgage backed security pools, the computer system in communicationwith one or more remote computers accessed by the one or more parties,the computer system comprising: a computer having a processor includinga computer usable medium storing a computer readable program and anetwork interface, wherein the computer readable program comprisessoftware modules including a pool selection module, an order creationmodule, a trade negotiation module, and an execution module; a datastorage system in communication with the computer via the networkinterface, the data storage system storing information relating to theplurality of mortgage backed security pools, each of which is associatedwith a CUSIP number a pool factor that is reflective of the principalleft to be distributed in each of the mortgage-backed security pools,and account information related to at least the one or more parties; andwherein the computer, operative with the computer readable program,provides information related to the plurality of mortgage backedsecurity pools to at least one of the parties; obtains securitization ofthe mortgage-backed security pools from a government sponsoredenterprise; receives from the at least one party an inquiry includingcriteria related to one or more mortgage backed security pools;transmits an inquiry message to a selected party, the inquiry messageincluding the criteria, receives from the selected party informationrelating to the one or more mortgage backed security pools based upon atleast a portion of the criteria, transmits the received information tothe at least one party, provide aggregate pool data related to theselected specified pool, provide information related to the selectedspecified pool to at least one other party, receive pricing informationfrom the at least one other party, and execute a trade for the mortgagebacked security pools in the specified pool.